home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940107.txt < prev    next >
Internet Message Format  |  1994-11-13  |  12KB

  1. Date: Sun, 10 Apr 94 04:30:13 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #107
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Sun, 10 Apr 94       Volume 94 : Issue  107
  11.  
  12. Today's Topics:
  13.                      Ham-Digital Digest V94 #102
  14.                            JNOS vs. WNOS ??
  15.                         sexually explicit talk
  16.                                  TAPR
  17.                            TAPR File server
  18.  
  19. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  20. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the Ham-Digital Digest are available 
  24. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: 7 Apr 94 18:38:24 GMT
  32. From: news-mail-gateway@ucsd.edu
  33. Subject: Ham-Digital Digest V94 #102
  34. To: ham-digital@ucsd.edu
  35.  
  36. Your message was received at 04/08/94  5:25pm
  37.  
  38.   ----- The following address had delivery problems -----
  39. STROHS  (User does not exist)
  40.  
  41. From: Ham-Digital Mailing List and Newsgroup <ham-digital@UCSD.EDU>
  42. Subject: Ham-Digital Digest V94 #102
  43. Date: Fri,  8 Apr 94 02:38:24 PDT
  44. To: To: strohs@strohpub.com
  45. Message-Id: <199404080938.CAA05222@ucsd.edu>
  46.  
  47.  
  48. ------------------------------
  49.  
  50. Date: 9 Apr 94 16:07:44 GMT
  51. From: agate!howland.reston.ans.net!pipex!demon!dakevar.demon.co.uk!duncan@ucbvax.berkeley.edu
  52. Subject: JNOS vs. WNOS ??
  53. To: ham-digital@ucsd.edu
  54.  
  55. In article <764557213.AA00617@afarm.uucp> Ted.Cross@f40.n382.z1.fidonet.org writes:
  56.  
  57. >Organization: MicroLithics Corp.
  58. >
  59. >
  60. >Hi there es tnx fer reading this.
  61. >
  62. >I've been a user of WNOS for some time and NOS before that. I've noticed
  63. >references to JNOS. I've had a quick look around one or two sites but
  64. >not found much info on JNOS. Has anyone out there got any insight into
  65. >the differences between WNOS and JNOS and which is better, I assume JNOS
  66. >is the new kid on the block and potentially the next generation!!
  67.  
  68. Ted,
  69.  
  70. We've been using WNOS4 for some time at GB7SIG and had no problems until 
  71. we had a sudden increase in user activity.   When the mail activity got 
  72. large WNOS could not cope.  We tried the beta version of WNOS5 but this 
  73. seems to suffer from the same problem.
  74.  
  75. We are now trying to set up JNOS but are having lots!!! of trouble.  Short
  76. answer is, if its for your own BBS then WNOS4 is great.  JNOS needs more work
  77. to get the setup right.  I have JNOS working at home but there seems to be
  78. a problem with memory.  The mailer does not work at present, probably because
  79. of the lack of memory so watch this space.
  80.  
  81. I look forward to your comments and perhaps info from other areas.
  82.  
  83. Best regards & 73's
  84.  
  85.  
  86. Duncan R Goodacre  G7EXG
  87.  
  88. ------------------------------
  89.  
  90. Date: 9 Apr 1994 04:31:12 GMT
  91. From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!yeshua.marcam.com!insosf1.infonet.net!usenet@network.ucsd.edu
  92. Subject: sexually explicit talk
  93. To: ham-digital@ucsd.edu
  94.  
  95. In article <765776764snx@skyld.grendel.com>, jangus@skyld.grendel.com (Jeffrey D. Angus) writes:
  96. >I found this over on rec.radio.amateur.packet. THought someone might wish to
  97. >give him a hand.
  98. >
  99. >In article <Cns42x.2Bu@iat.holonet.net> bgould@iat.holonet.net writes:
  100. >
  101. >  > 
  102. >  > Dear anyone,
  103. >  > I don't have a liscense, but I bought a ham radio recently and was thining
  104. >  > about opening sexually explicit gay chatline through info packets over the
  105. >  > air. Is  there any way the government could monitor these conversations,
  106. >  > as some of them could possibly involve underage men. If anyone is
  107. >  > inerested in subscribing to my packet service, feel free to contact me or
  108. >  > DeanSf@aol.com.
  109. >  > 
  110. >  > Thanx, 
  111. >  > 
  112. >  > bgould@holonet.net
  113. >  > 
  114. >  > 
  115. > Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding
  116. >Internet: jangus@skyld.grendel.com        |  a fanciful dimension to any
  117. > US Mail: PO Box 4425 Carson, CA 90749    |  story."
  118. >   Phone: 1 (310) 324-6080                |           Peking Noodle Co.
  119. >
  120. Hey! April 1st has passed us by!
  121. 73, Bill; W0OMV
  122. ax25: w0omv@wr9b.#wcil.il.usa.noam
  123. tcpip: w0omv.ampr.org [44.50.32.5]
  124. Internet: billh@ins.infonet.net
  125.  
  126. ------------------------------
  127.  
  128. Date: Sat, 9 Apr 1994 15:04:34 GMT
  129. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!noc.near.net!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!news@network.ucsd.edu
  130. Subject: TAPR
  131. To: ham-digital@ucsd.edu
  132.  
  133. The previosuly posted instructions for accessing TAPR's list server
  134. are incorrect. The proper address is "file-request@tapr.org". Don't
  135. send file requests to tapr@tapr.org!
  136.  
  137.         Mike Blackwell  --  ke3ig  --  mkb@cs.cmu.edu
  138.  
  139. ------------------------------
  140.  
  141. Date: 9 Apr 94 18:29:49 GMT
  142. From: news-mail-gateway@ucsd.edu
  143. Subject: TAPR File server
  144. To: ham-digital@ucsd.edu
  145.  
  146. It looks like I goofed in a message I sent out the other day.  The file
  147. server at TAPR can be reached at the address file-request@tapr.org.  To 
  148. get the help file and a list of available files, send a message to
  149.  
  150. file-request@tapr.org
  151.  
  152. In the body of the message, type the lines:
  153.  
  154. help
  155. dir
  156. quit
  157.  
  158. The information will be sent to you.  A reply-to line in your header will 
  159. help in cases where the return information is hard to decipher.
  160.  
  161. The address given previously, tapr@tapr.org goes to a human who will be
  162. glad to take your orders or process membership applications, etc., but 
  163. cannot send you the requested files.  This can only be done by the 
  164. file robot.
  165.  
  166. ------------------
  167. Bob Nielsen, W6SWE              Internet: w6swe@tapr.org
  168. Tucson, AZ                      Amateur IP: 44.124.12.16
  169.                                 ax.25: w6swe@wb7tls.az.usa.na
  170.  
  171. ------------------------------
  172.  
  173. Date: 8 Apr 1994 21:04:56 GMT
  174. From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com!hanko@uunet.uu.net
  175. To: ham-digital@ucsd.edu
  176.  
  177. References <Cnr9x1.II6@world.std.com>, <2nuqbe$omj@hpbab.mentorg.com>, <2nvfu0$1ve@ccnet.ccnet.com>
  178. Reply-To : Hank_Oredson@mentorg.com
  179. Subject : Re: NTS traffic on packet
  180.  
  181. In article <2nvfu0$1ve@ccnet.ccnet.com>, rwilkins@ccnet.com (Bob Wilkins  n6fri) writes:
  182. |> Hank Oredson (hanko@wv.mentorg.com) wrote:
  183. |> 
  184. |> : What would prevent duplicates or lost messages?
  185. |> : How would you accomplish this?  Remember we don't have a "fixed
  186. |> : configuration" network.  We don't have reliable paths.  We do have multiple
  187. |> 
  188. |> I don't understand. There are fixed routes in and out of any full service bbs.
  189.  
  190. Now I'm confused.  How are these routes fixed?  What happens when a
  191. forwarding partner goes off air?  What happens when a node goes down?
  192. How are backup routes handled?  I see "fixed routes" on a hour to hour
  193. basis, but not on a year to year basis. Often, not even on a week to week basis.
  194.  
  195. |> The HF routes may seasonally change and require manual assistence. 
  196. |> What is going to happen if the BBS protocol is allowed to be the rule on 
  197. |> the DASH digital amateur super highway. It is my understanding that the 
  198. |> proposal for the 219 MHz 56kb DASH will require point to point auxiliary 
  199. |> operation. Will the bbs protocol work in this new arena?
  200.  
  201. Well ... the bbs authors don't care much - this is just data transport.
  202. Bytes get from point A to pont B, not important how they get there.
  203. i.e. it has nothing to do with the bbs protocol.
  204.  
  205. |> Maybe the answer is to make the 219 MHz DASH a tcp/ip network and put the 
  206. |> bbs mail traffic into <envelopes> for safe transport across the network. I 
  207. |> would like to see some more discussion on the future implementation of 
  208. |> this new network. 
  209.  
  210. That is what we already do, but with other protocols: AX.25, NET/ROM,
  211. CLOVER, AMTOR, PACTOR, whatever. tcp/ip as tranport protocol has not made
  212. much inroad in the bbs network, for various reasons. It really does not
  213. matter what transport protocol is used, the bbs system does not care.
  214.  
  215. |> Has anyone done any traffic analysis of bbs messages? Are the bulk of the 
  216. |> messages two or three hops? With the increase in network speed will the 
  217. |> message flow naturally increase? Will my bbs mail reading program be able 
  218. |> to keep up with the vast number of bulletins that will be arriving? I 
  219. |> realize that I will be reading at 1200 for quite some time ... maybe 9600 
  220. |> if the bbs operators will provide this service. 
  221.  
  222. Yes, much traffic analysis.  The bulk of message traffic is "many hop".
  223. At each increase in network capability to date, traffic has increased to
  224. saturate the new capability within a short time. I already have users at
  225. 9600 baud, and they are asking for faster response ...
  226.  
  227. At least in the PNW, traffic has been running roughly equal volume (in
  228. bytes) between personal and bulletins, with twice as many personal messages
  229. as bulletins flowing through the system.        
  230.  
  231. One thing to think about though: we have two different services represented
  232. by the existing bbs network. There are single sender to single recipient
  233. messages (e.g. personal messages) and also single sender to multiple
  234. recipient messages (e.g. bulletins). We now tend to handle these messages
  235. types a little differently - mostly by giving some priority to the personal
  236. messages. Whatever transport mechanism we use will make little difference
  237. to the day to day operation of a bbs system though - the messages will come
  238. in, they will go out, users will send and read them.
  239.  
  240. |> Sorry Hank, I am not a network guru, just your average packet user. 
  241. |> 
  242. |> Bob
  243. |> 
  244. |> 
  245. |> : -- 
  246. |> 
  247. |> : Hank Oredson @ Mentor Graphics
  248. |> : Internet     : hank_oredson@mentorg.com
  249. |> : Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM
  250. |> 
  251. |> 
  252. |> 
  253. |> -- 
  254. |>      Bob Wilkins                     work    bwilkins@cave.org
  255. |>  Berkeley, California                home    rwilkins@ccnet.com
  256. |>      94701-0710                      play    n6fri@n6eeg.#nocal.ca.usa.noam
  257.  
  258. -- 
  259.  
  260. Hank Oredson @ Mentor Graphics
  261. Internet     : hank_oredson@mentorg.com
  262. Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM
  263.  
  264. ------------------------------
  265.  
  266. Date: Fri, 8 Apr 1994 18:53:46 GMT
  267. From: elroy.jpl.nasa.gov!swrinde!gatech!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!arrl.org!jbloom@ames.arpa
  268. To: ham-digital@ucsd.edu
  269.  
  270. References <01HATOE2L7VM91WF9U@stthomas.edu>, <1994Apr6.214215.2580@arrl.org>, <williams.765739386@maui>et
  271. Subject : Re: GTOR INFO
  272.  
  273. Paul Williamson (williams@maui.qualcomm.com) wrote:
  274. : jbloom@arrl.org (Jon Bloom (KE3Z)) writes:
  275. : >This is true.  it might have been better had G-TOR stuck to a 200-baud
  276. : >upper limit.  We have enough wide-bandwidth signals on the bands now.
  277.  
  278. : At least G-TOR only upshifts to 300-baud when it has enough data to
  279. : justify it.  It doesn't take up the wider bandwidth unless it needs to.
  280. : I don't see anything wrong with taking up bandwidth as long as you're
  281. : not wasting it.
  282.  
  283. Well, there are two problems.  The first is that many radios have as
  284. their available filter selections 2.1 kHz (or so) and 500 Hz. A
  285. 300-baud, 200-Hz-shift signal really needs a wider filter than 500 Hz.
  286. So 300-baud operators (like existing HF packet ops) tend to use their
  287. SSB filters. Then they can't tolerate interference on adjacent channels
  288. because the interfering signals fall within their filter passbands, so
  289. they space out to 2-kHz separation.  In this case, these stations *are*
  290. effectively taking up bandwidth that they aren't really using.
  291.  
  292. The second problem is that in an environment in which signals are not
  293. subbanded (if that's a word) by transmission mode, the use of signals
  294. of different widths make sharing the spectrum more difficult.
  295. -- 
  296. Jon Bloom KE3Z   jbloom@arrl.org
  297.  
  298. ------------------------------
  299.  
  300. End of Ham-Digital Digest V94 #107
  301. ******************************
  302.